Conversation
Add static registry of known x402 payment facilitators keyed by chain ID and address. Extend AddressType union with "x402Facilitator" and detect facilitator addresses before contract type checks for instant lookup.
Add FacilitatorInfoCard showing facilitator metadata (name, logo, description, website, base URL, schemes, assets, capability badges) and X402FacilitatorDisplay with contract info conditional on code presence. Wire into address page routing with i18n support (en/es).
Add 11 e2e tests covering facilitator type detection, info card rendering (name, logo, description, website, base URL, schemes, assets, capability badges), balance, transaction history, and conditional contract details display. Add PayAI and Kobaru to Base test fixtures.
|
🚀 Preview: https://pr-338--openscan.netlify.app |
There was a problem hiding this comment.
We can move this to our metadata repo, its ok for me if you want to do it after this PR or if you want to do it now. But if we dont do it now lets create an issue for it later.
There was a problem hiding this comment.
Lets review and merge this one. I'll create the metadata issue
…cilitators Add FieldLabel tooltips to FacilitatorInfoCard for Name, Base URL, Schemes, Assets, and Capabilities (visible for beginner/intermediate). Show x402 facilitators as "Account (EOA)" with an "x402 Facilitator" tag since they are primarily EOA accounts.
AugustoL
left a comment
AugustoL
left a comment
There was a problem hiding this comment.
I added helper tooltips and the address detection still shows the address and EOA acocunt with a x402 tag
josealoha666
left a comment
josealoha666
left a comment
There was a problem hiding this comment.
Good direction overall. One UI issue still seems present on the current head: AddressHeader already renders the type label from getAddressTypeLabel(addressType), so for x402Facilitator it already shows x402 Facilitator. The extra hardcoded badge added right after that renders the same classification a second time, which matches Augusto's note that the header is still showing the generic address/account labeling plus an x402 tag.
I'd drop the extra addressType === "x402Facilitator" badge and let the type label/icon carry that classification, while keeping tokenName for the facilitator name.
3 participants
Description
Adds x402 payment facilitator detection and display to the address page. When viewing an address that matches a known x402 facilitator (e.g., PayAI, Bitrefill, Kobaru), OpenScan now shows a dedicated display with facilitator metadata including name, description, website, supported schemes, assets, and capabilities.
Related Issue
Type of Change
Changes Made
2b4dda6): Addedx402Facilitatoraddress type tosrc/types/index.tsand detection logic insrc/utils/addressTypeDetection.tsthat matches addresses against a static registrysrc/config/x402Facilitators.ts): Created a chain ID → address lookup map of known x402 facilitators across Base, Ethereum, Arbitrum, Optimism, BSC, Polygon, Avalanche, and Sepolia — includes facilitators like PayAI, Bitrefill, Coinbase Developer Platform, Kobaru, and others21eb9b5):X402FacilitatorDisplay— full address page display with contract verification, proxy detection, AI analysis, and transaction historyFacilitatorInfoCard— card showing facilitator name/logo, description, website, base URL, schemes, assets, and capability badges (verify/settle/supported/list)enandeslocalessrc/styles/components.css5201935): Playwright tests verifying facilitator detection, info card display, capability badges, and contract details for PayAI and Kobaru on BaseScreenshots (if applicable)
Checklist
npm run format:fixandnpm run lint:fixnpm run typecheckwith no errorsnpm run test:runAdditional Notes
The facilitator registry is a static config file. As new x402 facilitators emerge, entries can be added to
src/config/x402Facilitators.tswithout code changes beyond the config. The display component follows the same pattern as other address type displays (ERC20, ERC721, etc.).